Optimizing use of hardware security modules

ABSTRACT

Use of cryptographic key-store hardware security modules is optimized in a system having a first scarce high-security key storage device and a second more plentiful low-security key storage device comprising securing a cryptographic key to the higher security level by initially storing the key in the first storage device, then responsive to an event, evaluating the stored key against one or more rules, and subsequent to the evaluation, reclassifying the stored key for relocation, encrypting the reclassified key using a key-encryption key; relocating the reclassified key into the second, lower-security storage device, and storing the key-encryption key in the first storage device.

CROSS-REFERENCE TO RELATED APPLICATIONS (CLAIMING BENEFIT UNDER 35U.S.C. 120)

This is a continuation application of U.S. patent application Ser. No.12/782,551, filed on May 18, 2010, by Krishna K. Yellepeddy, et al.

FEDERALLY SPONSORED RESEARCH AND DEVELOPMENT STATEMENT

This invention was not developed in conjunction with any Federallysponsored contract.

MICROFICHE APPENDIX

Not applicable.

INCORPORATION BY REFERENCE

The following published documents are incorporated by reference in theirentireties:

-   (a) “IBM Crypto Server Management General Information Manual”,    document CSM-1000-01, First Edition, May, 2000, published by    International Business Machines Corp.-   (b) “IBM PCI Cryptographic Coprocessor General Information Manual”,    Sixth Edition (May 2002), published by International Business    Machines Corporation.-   (c) “Federal Information Processing Standards Publication: Security    Requirements for Cryptographic Modules”, FIPS PUB 140-2, Jan. 1,    1994, published by the U.S. Department of Commerce, National    Institute of Standards and Technology.

BACKGROUND

Field of the Invention

The invention generally relates to Hardware Security Modules employed incryptographic key management technologies.

Background Information

Many electronic and online transactions utilize cryptographic keysbetween two or more cooperating computers in order to protect sensitiveinformation, such as personal information, credit card numbers,transaction authorizations, and the like. One widely used cryptographickey process is Public Key Infrastructure (PKI), but many others exist aswell, including proprietary and other “public” or “open” key processesand standards.

Creation of new cryptographic keys (hereinafter “keys”), and use of themto decode and encode protected data is process-intensive. For smallcomputers which are only serving a few processes at one time, such as ahandheld personal computer or a desktop computer, these processes mayreasonably be handled in software modules without noticeable detrimentto the performance or responsiveness of the small computer.

However, for larger computing environments, such as web servers andElectronic Data Interchange servers, creation of keys and key-basedoperations (encryption/decryption) for a large number of processessimultaneously, such as a large number of connections to web browsers orelectronic Automatic Teller Machines, can be so resource intensive thatperformance of the servers is severely degraded for specifiedperformance criteria such as maximum time to process a particulartransaction, latency to use of real time data, etc.

As more and more client computers attach to electronic networks such asWi-Fi, LAN, intranets, and the World Wide Web, and as more and moresensitive transactions are added to the networked environment, such asstock trading on wireless phones, the demand on servers to create anduse keys is growing significantly.

Existing architectures of hardware, software, and networking addressthese demands only to a certain extent. Specialized “co-processor”hardware is available which either installs into a server, or whichnetworks to a server, in order to off-load the key creation and keyusage operations from the rest of the server's functions, leaving theserver to handle other tasks such as web page serving, dynamicgeneration of HTML, database management, etc.

Similarly, appropriate storage of cryptographic keys is important tomaintain the security value of any cryptographic arrangement, whereasunauthorized access to keys may ultimately lead to unauthorized accessto the data they protect, thereby comprising the entire arrangement.Standards have evolved in the industry to allow buyers and purchasers tounderstand the relative security level of products and services beingoffered by the various vendors. One such standard is known as FIPS 140,or Federal Information Processing Standard 140, promulgated by theNational Institute of Standards and Technology (NIST). It requires aparticular validation program in order for a new product or service tobe certified to a particular level of security, wherein Level 1 is thelowest level of security and generally requires the least resources tomeet, and Level 4 is the highest level of security but also generallydemands the greatest resources.

In order to meet and maintain certain “levels” of security, then,specialized key storage hardware has been developed, referred to asHardware Security Modules (“HSM”). While the term sounds generic out ofcontext, in the context of cryptographic computing, HSM specificallyrefers to specialized hardware-based key storage which meets a specifiedsecurity level.

One widely-used solution for key creation, use, storage and managementis from International Business Machines Corporation (IBM)™, known asCrypto Server Management (CSM), which makes possible centralization ofthe management of cryptographic accelerator hardware and HSM, inparticular IBM 4758 PCI Cryptographic Coprocessors, which are installedin remote computers. Using such an arrangement has lessened the need forlocal crypto-skilled personnel, reduced on-site support of cryptocoprocessors from skilled personnel, enabled quick recovery after anunplanned stop of crypto-coprocessors, provided new crypto-functions,and allowed new keys to be introduced centrally with no need for localprocedures. Additionally, there is no need for unsecured or difficultprocedures for backup of keys, and no need for shipping initializedcoprocessors (the tamper resistance of a 4758 makes it sensitive forphysical handling with the risk that a initialized 4758 is useless atarrival and must be reinitialized). The security benefits provided bysuch an arrangement include no vulnerability of local keys, no exposureof exchanged keys, centralized control over code and all keys in thenetwork, defined level of security can be easily enhanced when needed,and no need for having tight control over shipped initialized 4758s.

SUMMARY OF THE INVENTION

The invention automatically manages the lifecycle of keys and theirtransition to lower quality key-stores as the keys become less critical.The use of the cryptographic key-store hardware security modules isoptimized in a system having a first scarce high-security key storagedevice and a second more plentiful low-security key storage devicecomprising securing a cryptographic key to the higher security level byinitially storing the key in the first storage device, then responsiveto an event, evaluating the stored key against one or more rules, andsubsequent to the evaluation, reclassifying the stored key forrelocation, encrypting the reclassified key using a key-encryption key;relocating the reclassified key into the second, lower-security storagedevice, and storing the key-encryption key in the first storage device.

A benefit of the present invention is that a larger number ofcryptographic keys can be managed in the more secure environmentprovided by Hardware Security Modules, which reduces cost of operationand compliance to the customer or owner of a computing environment.

BRIEF DESCRIPTION OF THE DRAWINGS

The following detailed description when taken in conjunction with thefigures presented herein provide a complete disclosure of the invention.

FIG. 1 illustrates logical processes according to the present invention.

FIG. 2 depicts an “On-line” configuration of Crypto Server Management(CSM).

FIG. 3 shows a “Stand-alone” “configuration of Crypto Server Management(CSM).

FIG. 4 sets forth a block diagram of the architecture of a HardwareSecurity Module with embedded cryptographic co-processor.

FIG. 5 illustrates a logical process of extended key managementaccording to the invention.

DETAILED DESCRIPTION OF ONE OR MORE EMBODIMENTS OF THE INVENTION

The present inventors have identified a problem in the art relating tosecure storage and management of cryptographic keys (hereinafter “keys”)not previously recognized by those skilled in the art. The recognizedproblem stems from the fact that the number of keys in a customerenvironment keeps growing. Compounding the problem is that some of thesecustomers have a requirement to keep these keys in a hardware basedkey-store in order to comply with regulations or business policies. But,hardware security modules (HSM) have limited space, e.g., some hardwaremodules have as little as 64 KB of secure data storage for keeping alimited number of keys and handles.

The inventors have realized that, for a centralized key manager with alarge number of cryptographic keys, it may not be possible to store allthe keys in a hardware based key-store because of limited space in thekey-store. The solution envisioned by the inventors is to provide a wayto transition the keys from highly-secure, expensive and scarce hardwarestorage to less expensive, more plentiful and potentially less-secureforms of key-stores. A problem solved by the inventors to achieve suchimprovement in the art has been determining how to use hardware securitymodules to their best advantage while avoiding keeping all key materialsin the hardware security modules.

As the reader will recognize from the following detailed description ofthe invention and embodiments according to the invention, a first pointof novelty of this invention is that a set of rules are definedcontrolling encryption key classification and storage location as afunction of key usage and data usage (e.g. data protected by keys). Forexample, a high frequency of usage of a key for decryption of data ondifferent storage media may imply there is a large amount of dataencrypted with this key, and therefore, according to management rules,that key is kept in higher secure storage longer. Conversely, a lowlevel of usage of a key (or the data it protects) may indicate that thekey protects a small amount of data or less important data, and thus thekey can be moved to a lower secure storage with certain provisions asset forth in the following paragraphs.

Basic Crypto Server Arrangements

Crypto servers typically comprise a “standard” or well known computingplatform, such as an IBM AS/400 server, a “PC”-based server, etc.,running any suitable operating system, such as IBM AIX™, OS/2 ™, UNIX™,Microsoft Windows NT™, etc.

The following description of basic CSM arrangements is taken from “IBMCrypto Server Management General Information Manual”, documentCSM-1000-01, First Edition, May, 2000, published by InternationalBusiness Machines Corp.

From a CSM point of view, a set-up of Crypto Servers in a network can beof any kind. It can support e.g. a Branch network where a lot ofbranches each have one or more Crypto servers. Or, it can support a morecentralized set-up where the Crypto Servers to manage all are centrallylocated in one or more machine halls.

Both set-ups can be separately defined within CSM, but it can also bemixed, making it possible that keys at the central Crypto Servers canalso be present at the Branch Crypto Servers.

How a specific Crypto Server set-up looks at each customer, or howdifferent Crypto Server set-ups are mixed is a fully customizablepossibility.

A Crypto Server set-up (200) might look as illustrated in FIG. 2, if acentral host (201) communicating with the Crypto Servers (203, 204, 205,206) is involved. This is called the CSM On-line version.

The On-line version enables keys generated for the Crypto Server to bedirectly available also for OS/390 Integrated Cryptography ServiceFacility (ICSF) (or IBM 4753) on up to 30 logical partitions (LPARs),making it possible to ensure communication between host and CryptoServers.

All keys are stored on OS/390 DB2 tables, taking advantage of normalback-up and recovery procedures on OS/390.

If the set-up does not include a central host, CSM in a Stand-aloneset-up (300) still makes it possible to administer the Crypto Servers,as shown in FIG. 3. In the Stand-alone version, keys are stored locallyon the CSM Workstation (202′) (and must be backed up locally).

As indicated by the ellipses “ . . . ” in both FIGS. 2 and 3, the CSMhas no problem supporting exchange of keys with other platforms andother Crypto engines than the IBM 4758 and 4755.

The CSM can be customized to support other Crypto Architectures than CCA(Common Cryptographic Architecture) from IBM. From the Key exchangeperspective, it is therefore possible to generate and exchange keys withnon-IBM Crypto engines. It is also possible to mix the hierarchy so thatkeys are generated for both the IBM world and other Crypto engines.

From CSM perspective, all that needs to be done is to define the newCrypto architecture within CSM and exchange the 4758/4755-APIs of theCSM programs on the Crypto Server with the APIs from the relevant Cryptovendor.

More general information on CSM configurations may be found by thereader in the aforementioned publication. It will be readily recognizedby those skilled in the art that the present invention is not limited touse and implementations in conjunction with the specific hardware andsoftware components which will be described in the following paragraphs,but rather, the invention may be also use in conjunction with othercryptographic key storage systems, product, technologies, and services.The specific hardware and software mentioned herein are for exampleillustration only.

Basic HSM Architecture

It will be useful for understanding the present invention to alsounderstand the general architectures of Cryptographic Key HardwareSecurity Modules (HSM). The following detailed description of an IBM4758 will be used to illustrate the more general concepts which arepresent in most HSM's. It will be recognized by those skilled in the artthat the present invention is not limited to implementation with orusefulness with only this particular HSM, but instead, its benefits maybe realized with a wide array of HSM products.

The following information is taken from “IBM PCI CryptographicCoprocessor General Information Manual”, Sixth Edition (May 2002),published by International Business Machines Corporation.

The cryptographic Coprocessor subsystem (403), shown schematically inFIG. 4, has of these elements:

(a) Tamper Detection Sensors. Models 001 and 002 and Models 013 and 023differ in the approach to tamper detection. The FIPS 140-1 level 4 ratedModels 001 and 002 surround the internal electronics with a polyurethanemixture and a film with an imprinted circuit pattern to detect minutepenetration and erosion attacks. The FIPS 140-1 level-3-rated Models 013and 023 employ an electrical circuit connected to the steel case todetect attempts at opening the case. Additional environmental sensorsimplement additional tamper-detection techniques. The Models 001 and 002implement a full complement of techniques to monitor environmentalconditions: high and low temperature, power sequencing, and radiation.All of the sensors are continuously powered from the time of factoryinitialization and certification to the end of productive life of theCoprocessor. Any sensor-detected tamper event causes immediate powerloss to the battery-backed RAM (407) resulting in zeroization of thismemory, and a subsystem reset resulting in a processor shutdown and theend of RAM-memory refresh cycles. The result is the immediatedestruction of any sensitive data stored in these memories and the CPU.

(b) Central Processing Unit (CPU). A 486-class CPU provides anindustry-standard computing environment for flexible control of secureprocessing and cryptographic algorithms and processes.

(c) PCI Bus Interface Processor Module. This module (404) couples thesecured electronics to the PCI bus (401) and provides for busmasteroperation with inbound and outbound DMA operations (402) between theFIFO buffers and the host-system memory. The module also providesmailboxes and interrupts to permit the exchange of control informationbetween the Coprocessor and the host-system Coprocessor device driver.

(d) DES Engine. The DES engine (409) provides DES processing at highsustained rates. All models support 56-bit CBC and ECB DES encryption.Models 002 and 023 also support three-key triple-DES in outer CBC andECB modes. Because of the need to inject keys under control of thesubsystem software, to setup the FIFO buffer connection controls, and toinitialize the DMA controllers, throughput is sensitive to the datablock-size and to the host-system bus design and load.

(e) Random-Number Generator. An electronic noise source providesunpredictable input to a random bit-value accumulator (410). (The CP/Q++control program periodically uses the hardware output to seed a FIPS140-1 approved pseudo random-number generator. The control programprovides both the raw accumulated hardware output and the pseudorandom-number generator output to internal application programs.)

(f) Large-Integer Modular Arithmetic Processor. A 1024-bit or2048-bitmodular-arithmetic processor (411) supports the processing thatis the basis of cryptographic algorithms such as RSA, Diffie-Hellman,and DSA.

(g) Clock Calendar. A time and date source (412) accurate to within oneminute per month provides a internal time value that is under theexclusive control of software running within the subsystem.

(h) RAM Memory. DRAM memory (408) is available for the use of subsystemsoftware and data storage.

(i) Flash Memory. Two or four megabytes of electrically erasable,persistent-data memory (406) are incorporated in the design. IBMprovides software to selectively encrypt sensitive data stored in flashmemory. The encryption keys used for this are stored in battery-backedRAM and are zeroized in the event of a detected tamper event.

(j) Battery-Backed Random Access Memory (BBRAM). As with flash memory, acontrol program can restrict access to the battery-backed RAM (407).Read and write times are comparable to that of DRAM. The contents ofthis memory are quickly zeroized in the event of a detected tamper.

Other functions of the IBM 4578 shown in FIG. 4 are eitherself-explanatory, or may be understood by referencing the aforementionedpublication. The functions and circuits described in the precedingparagraphs (a) through (j) are utilized in at least one embodiment ofthe present invention as set forth in the rest of this description.

Logical Processes

The following logical processes form a part of an embodiment accordingto the invention. In one possible embodiment, the following logicalprocesses are implemented in software (or firmware) executed by aprocessor of a HSM, such as the 486-class microprocessor of an IBM 4578HSM. In such an embodiment, the realization includes both the software(or firmware) and the requisite hardware processor, memory devices,clocks, buses, etc., to form a specific HSM machine having the newfunctionality as described herein.

In an initial phase of the logical process, which may be repeated or maybe multi-threaded for concurrent, asynchronous performance, someattributes of key material are identified that can be stored outside thehigher security hardware storage. These attributes form part of a ruleset for controlling the HSM's new actions. Because of limited highsecure hardware storage space, some, but not all, of the in-use keys areselectively moved from higher-secure, space-limited memory into alower-secure but less-expensive, more plentiful database. The relocatedkeys, however, are encrypted themselves using a new key which is thenstored in the higher security hardware key-store. We will refer to theprocess of designating certain keys and key material as eligible forrelocation from hardware key-store to database as “reclassification”.The new key created to encrypt the relocated keys, and which is storedin the higher-security hardware storage, will be referred to as a“key-encryption key” (KEK).

One benefit of this process is that handling disaster preparedness isthat only the KEK's must be backed up in to secure storage, while therelocated (and encrypted) keys only must be backed up per lower securityprocesses such as normal database backup mechanisms. As such, ahierarchy of key-stores with different security profiles/properties isrealized, e.g. the 4758 HSM is at the top at FIPS 140 level 4, where thedatabase holding the relocated (and encrypted) keys may be just FIPS 140level 1 or 2.

Turning now to FIG. 1, these logical processes (500) are illustratedwhere an abstraction layer (501) allows different crypto-coprocessorsand hardware key store controllers (506) to access and control (502) thenew hierarchical, rules-driven extended key management (550) functionsvia a Hardware Key-Store (HWKS) Interface (I/F). This allows theexemplary embodiment to interoperate with any of a variety ofcrypto-coprocessors and hardware key store controllers.

Unique triggers on how keys get reclassified are embodied in thisexample in rule sets (504) used by the Extended Key Management (550)such as the following:

(a) Key Life-cycle Triggers. These rules operate using a timer or clocksource (505) to cause the expiration of keys, certificates, and relatedkey materials (KC&KM). KC&KM that are near expiration or have expiredmay be reclassified according to the rules to be relocated intolower-security storage (508) from the scarce, higher-security hardwarestorage (507), being encrypted (501) during relocation by akey-encryption key, and decrypted (511) upon reclassification andrelocation back into scarce, higher-security hardware storage (507). Akey location table (509) is used by the extended key management (550) tokeep track of where each key is stored, and whether it must be decryptedusing a key-encryption key before it is used.

(b) Protected Data Life-cycle Triggers. These rules operate using atimer or clock source (505) to cause the expiration of data which isprotected by keys stored in the hardware key memory (507) or the softkey storage (508). When data designated as having an expiration dateages to near or past its expiration date, the key protecting that datais reclassified and relocated from the hardware key memory (507) to thesoft key storage (508).

(c) Key Usage Triggers. These rules operate using a counter and a timeror clock to track how often or how recently each key stored in thehigher-security key memory (507) has been used in a key operation. Ifthe frequency of use reaches a minimum threshold, or the time since lastuse reaches a maximum threshold for a particular key, then the key isreclassified and relocated from the hardware key memory (507) to thesoft key storage (508).

(d) Protected Data Usage Triggers. These rules operate using a counterand a timer or clock to track how often or how recently data which isprotected by a key stored in the higher-security key memory (507) hasbeen used in a key operation. If the frequency of protected data usereaches a minimum threshold, or the time since last use of the protecteddata reaches a maximum threshold for a particular key, then theassociated key is reclassified and relocated from the hardware keymemory (507) to the soft key storage (508).

A usage limit may be reached for the amount of data that has beenencrypted after which the key is no longer used for encrypting new data.However, the key has been used to encrypt critical, confidential dataand must continue to be maintained in highly secure storage even thoughof low key usage may indicate a lower classification, until the datathat has been encrypted is classified to a lower level of criticality.

(e) Key Revocation Triggers. These rules operate to reclassify andrelocate keys that have been revoked, whereas even though keys have beenrevoked, certain computing applications require the keys to bemaintained for some extended period of time to meet legal, regulatory,or other compliance issues.

(f) Protected Data Reclassification Triggers. These rules operate toreclassify a key which is currently stored in hardware key memory (507)when the data that the key protects is reclassified. If the protecteddata is reclassified to a lower criticality, archived, or destroyed,then the key that protects that data is also reclassified and relocatedinto lower-security key storage (508).

For brevity in the foregoing paragraphs, the description ofreclassifying and relocating of keys from higher-security hardwarestorage (507) to lower-security soft storage (508) has not explicitlystated in each example that the key being relocated is encrypted (510)using a key-encryption key (KEK), and that the key-encryption key (KEK)is then stored in the hardware key-store (507). These steps, however,are followed in each of the examples, and are implied in the steps ofreclassification and relocation.

Now referring to FIG. 5, the extended key management process (550) isshown in more detail, which begins by receiving (551) a request for anew key, a key operation, or access to data protected by a key which therequester expects to be stored in HSM (e.g. which would normally bestored in HSM according to the key management interface). However, sincea process according to the invention is in place, a check (552) is madeto determine if the key is currently actually in HSM or is stored insoft key-store. If it is currently in HSM, then the rules (504) arechecked (553), and if any triggers are met (554), the key isreclassified, encrypted by a KEK (555), the key is moved (556) to softkey-store (508), and the KEK is stored (556) in the HSM (507), followingwhich, the data may be accessed by decrypting the key using the KEK(561).

If no triggers are met (554), then the key is used normally (562) fromthe HSM (507).

If, however, the key is already in soft key-store (508) at the check(552), then the rules are checked (558). If any triggers are met, thenthe key is decrypted using the KEK and reclassified (559), and movedfrom soft key-store to HSM, following which, the key is used normally(562) from HSM. If no triggers are met (e.g. key is to remain in softkey-store), then the KEK is used to temporarily decrypt the key (561)for usage to access the data.

Computer Readable Storage Media Embodiments

It will be understood by those skilled in the art that certainembodiments of the present invention may include part or whole of thelogical processes realized in circuitry, such as custom integratedcircuitry and programmable logic devices. Yet, in other embodimentsaccording to the invention, the logical processes may be realized inpart or whole as software or firmware executed by a processor andrequisite support circuitry, such as an HSM.

In the latter software-inclusive or firmware-inclusive embodiments, thesoftware or firmware may be stored temporarily or long term in anysuitable computer readable storage media such as RAM, ROM, hard disk,Compact Disc (CD), Digital Versatile Disc (DVD), etc. Additionally, suchsoftware or firmware may be initially stored on a first computer anddownloaded to a second computer, where it is then stored in storagemedia of the second computer for execution by the second computer or forfurther transmission or forwarding to other computers. “Downloading” inthis context is meant to include any means of transmitting the softwareor firmware from one computer to another, including client-server andpeer-to-peer transmissions, and transfer over wired and wirelessnetworks.

For example, the first computer may be a server, and the second computermay be a client (client-server arrangement). Or, both computers may beservers or both may be clients (peer-to-peer arrangement). Thedownloading means or transmission means may include a range oftechnologies, including but not limited to a Local Area Network (LAN), aWide Area Network (WAN), an Intranet, an Internet, a World Wide Web, andvarious wireless networks, such as a Wi-Fi network, BlueTooth™, infrared(IrDA), radio modem, and wireless telephone networks.

CONCLUSION

The present invention has been described by setting forth certainoperational and design concepts, and by providing certain specificembodiment examples using specific hardware and software details. Itshould be understood by those skilled in the art that these examples tonot represent the scope and limits of the present invention, whereasother embodiments according to the invention may utilize other suitablehardware and software components.

What is claimed is:
 1. A method for optimizing use of cryptographickey-store hardware security modules comprising: securing by a processorat least one cryptographic key in a hardware security module; responsiveto a first trigger being met: reclassifying, by a processor, thecryptographic key; generating, by a processor, a key-encrypting-key; andencrypting, by a processor, the cryptographic key using thekey-encrypting-key; responsive to the reclassifying, freeing memoryspace occupied in the hardware security module by the cryptographic keyby relocating, by a processor, the encrypted cryptographic key into asoft key store; and subsequent to the relocating and responsive to arequest to access data secured by the cryptographic key: decrypting by aprocessor the encrypted cryptographic key in the soft key store whileretaining the cryptographic key in the soft key store; and using by aprocessor the decrypted cryptographic key to provide access to secureddata per the request; wherein a security certification level of thehardware security module is greater than a security certification levelof the soft key store.
 2. The method as set forth in claim 1 furthercomprising: responsive to a second request to access the data secured bythe cryptographic key, evaluating by a processor the relocated keyagainst one or more rules; responsive to a second trigger being met:reclassifying by a processor the cryptographic key; decrypting by aprocessor the cryptographic key using the key-encryption-key; relocatingby a processor the decrypted cryptographic key into the hardwaresecurity module; and responsive to a subsequent request to access thedata secured by the cryptographic key, using by a processor thecryptographic key to provide access to the secured data per the requestwhile retaining the cryptographic key in the hardware security module.3. The method as set forth in claim 1 wherein the soft key storecomprises a database.
 4. The method as set forth in claim 1 wherein thefirst trigger comprises at least one event selected from the groupconsisting of a key revocation event, and a key expiration event.
 5. Themethod as set forth in claim 1 wherein the first trigger comprises atleast one rule selected from the group consisting of a key life cyclepolicy or rule, a key life cycle policy or rule, a data life cyclepolicy or rule, a key usage policy or rule, a data usage policy or rule,and a data reclassification policy or rule.
 6. The method as set forthin claim 1 wherein the hardware storage module comprises hardwaresecurity in compliance with a Federal Information Processing Standard140 encypher level selected from the group consisting of encypher levelfour, encypher level three, and encypher level two.
 7. A computerreadable storage memory device for optimizing use of cryptographickey-store hardware security modules comprising: one or more tangible,computer-readable storage memory devices; and first program instructionsfor causing a processor to secure at least one cryptographic key in ahardware storage module; second program instructions for, responsive toa first trigger being met, causing a processor to: reclassify thecryptographic key; generate a key-encrypting-key; and encrypt thecryptographic key using the key-encrypting-key; third programinstructions for causing a processor to, responsive to thereclassifying, free memory space occupied in the hardware securitymodule by the cryptographic key by relocating the encryptedcryptographic key into a soft key store; and fourth program instructionsfor causing a processor to, subsequent to the relocating and responsiveto a request to access data secured by the cryptographic key: decryptthe encrypted cryptographic key in the soft key store while retainingthe cryptographic key in the soft key store; and use the decryptedcryptographic key to provide access to secured data per the request;wherein a security certification level of the hardware security moduleis greater than a security certification level of the soft key store. 8.The computer program product as set forth in claim 7 further comprising:fifth program instructions for causing a processor to, responsive to asecond request to access the data secured by the cryptographic key,evaluate the relocated key against one or more rules; sixth programinstructions for causing a processor to, responsive to a second triggerbeing met: reclassify the cryptographic key; decrypt the cryptographickey using the key-encryption-key; relocate the decrypted cryptographickey into the hardware security module; and seventh program instructionsfor causing a processor to, responsive to a subsequent request to accessthe data secured by the cryptographic key, use the cryptographic key toprovide access to the secured data per the request while retaining thecryptographic key in the hardware security module.
 9. The computerprogram product as set forth in claim 7 wherein the soft key storecomprises a database.
 10. The computer program product as set forth inclaim 7 wherein the first trigger comprises at least one event selectedfrom the group consisting of a key revocation event, and a keyexpiration event.
 11. The computer program product as set forth in claim7 wherein the first trigger comprises at least one rule selected fromthe group consisting of a key life cycle policy or rule, a key lifecycle policy or rule, a data life cycle policy or rule, a key usagepolicy or rule, a data usage policy or rule, and a data reclassificationpolicy or rule.
 12. The computer program product as set forth in claim 7wherein the hardware storage module comprises hardware security incompliance with a Federal Information Processing Standard 140 encypherlevel selected from the group consisting of encypher level four,encypher level three, and encypher level two.
 13. A system foroptimizing use of cryptographic key-store hardware security modulescomprising: one or more computer microprocessors; and one or moretangible, computer-readable storage memory devices, encoding programinstructions for causing the processor to perform operations of:securing by a processor at least one cryptographic key in a hardwaresecurity module; responsive to a first trigger being met: reclassifying,by a processor, the cryptographic key; generating, by a processor, akey-encrypting-key; and encrypting, by a processor, the cryptographickey using the key-encrypting-key; responsive to the reclassifying,freeing memory space occupied in the hardware security module by thecryptographic key by relocating, by a processor, the encryptedcryptographic key into a soft key store; and subsequent to therelocating and responsive to a request to access data secured by thecryptographic key: decrypting by a processor the encrypted cryptographickey in the soft key store while retaining the cryptographic key in thesoft key store; and using by a processor the decrypted cryptographic keyto provide access to secured data per the request; wherein a securitycertification level of the hardware security module is greater than asecurity certification level of the soft key store.
 14. The system asset forth in claim 13 wherein the encoded program instructions furthercomprise program instruction for causing the processor to performoperations of: responsive to a second request to access the data securedby the cryptographic key, evaluating by a processor the relocated keyagainst one or more rules; responsive to a second trigger being met:reclassifying by a processor the cryptographic key; decrypting by aprocessor the cryptographic key using the key-encryption-key; relocatingby a processor the decrypted cryptographic key into the hardwaresecurity module; and responsive to a subsequent request to access thedata secured by the cryptographic key, using by a processor thecryptographic key to provide access to the secured data per the requestwhile retaining the cryptographic key in the hardware security module.15. The system as set forth in claim 13 wherein the soft key storecomprises a database.
 16. The system as set forth in claim 13 whereinthe first trigger comprises at least one event selected from the groupconsisting of a key revocation event, and a key expiration event. 17.The system as set forth in claim 13 wherein the first trigger comprisesat least one rule selected from the group consisting of a key life cyclepolicy or rule, a key life cycle policy or rule, a data life cyclepolicy or rule, a key usage policy or rule, a data usage policy or rule,and a data reclassification policy or rule.
 18. The system as set forthin claim 13 wherein the hardware storage module comprises hardwaresecurity in compliance with a Federal Information Processing Standard140 encypher level selected from the group consisting of encypher levelfour, encypher level three, and encypher level two.